Skip to content

refactor: use wasm-harness - #397

Merged
sinui0 merged 1 commit into
devfrom
refactor/wasm-harness
May 20, 2026
Merged

refactor: use wasm-harness#397
sinui0 merged 1 commit into
devfrom
refactor/wasm-harness

Conversation

@sinui0

@sinui0 sinui0 commented May 13, 2026

Copy link
Copy Markdown
Collaborator

Switch wasm test/bench runner to wasm-harness

Summary

Replaces the wasmtime --wasi threads runner with wasm-harness, which executes wasm32-wasip1[-threads] binaries under a chosen engine (wasmtime, V8/d8, SpiderMonkey/sm) via a bundled WASI polyfill. Enables running cargo test / cargo bench against the same JS engines used in browser-targeted benches, without source changes.

Changes

  • .cargo/config.toml
    • Added a [target.wasm32-wasip1] entry mirroring the threaded target's rustflags (atomics, bulk-memory, mutable-globals, simd128, 4 GiB max memory).
    • Both wasm32-wasip1 and wasm32-wasip1-threads now use runner = "scripts/wasm-runner.sh".
  • scripts/wasm-runner.sh (new, executable)
    • Auto-detects host core count (nproc on Linux, sysctl hw.ncpu on macOS, fallback 1) and exports WASM_HARNESS_ENV_RAYON_NUM_THREADS=<cores>.
    • wasm-harness forwards env vars prefixed with WASM_HARNESS_ENV_ into the guest with the prefix stripped, so rayon sees RAYON_NUM_THREADS without polluting the host shell.
    • Pre-existing WASM_HARNESS_ENV_RAYON_NUM_THREADS is respected (user override).
    • execs wasm-harness with cargo-supplied args.

Usage

Prerequisites: cargo install wasm-harness. For JS engines, npm i -g jsvu && jsvu to install v8 / sm shells. With no engine selected, wasm-harness picks the first available from $PATH / ~/.jsvu/bin.

cargo test  --target wasm32-wasip1
cargo bench --target wasm32-wasip1-threads
WASM_HARNESS_ENGINE=sm cargo bench --target wasm32-wasip1   # pick SpiderMonkey

Engine can also be selected per-invocation by editing the script to pass --engine <name>, or by setting WASM_HARNESS_ENGINE in the environment.

Notes

  • wasm-harness propagates a default whitelist of host env vars into the guest; the WASM_HARNESS_ENV_ prefix is the explicit escape hatch used here to set RAYON_NUM_THREADS without depending on whitelist contents.
  • --inherit-env is available on wasm-harness if you'd rather forward every host env var instead of using the prefix.
  • Bench code that builds its own rayon pool with an explicit num_threads() will ignore RAYON_NUM_THREADS — that's a per-bench concern, not a runner one.

@sinui0 sinui0 changed the title refactor: use wasm-runner refactor: use wasm-harness May 20, 2026
@sinui0
sinui0 force-pushed the refactor/wasm-harness branch from c9de7ad to a9df2a3 Compare May 20, 2026 18:22
@sinui0
sinui0 merged commit b0f6ead into dev May 20, 2026
4 checks passed
@sinui0
sinui0 deleted the refactor/wasm-harness branch May 20, 2026 18:24
@themighty1

Copy link
Copy Markdown
Contributor

@sinui0 , could you commit the usage notes to the repo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants